Companies and other organizations typically maintain information about many different aspects of the organization in order to ensure efficient operation. This organizational information (or organizational data) describes people, resources, applications, and the like, which make up the organization. For example, organizational information descriptive of an employee may include his/her name, job title, salary, telephone number, and/or internet protocol (IP) address. Organizational information describing an application may include the application's name and associated services provided by the application. Organizational information describing a resource may describe the resource as a network device (e.g., a printer), the name of the device, and capabilities provided by the network device. Many other types of organizational information may be maintained.
The organizational information is typically maintained in a number of remote data storage repositories, such as databases, directories, text files, and so on. For example, the human resources (HR) department may have a data repository of all employees in the company, with employee information. The information technology (IT) department may have a data repository of all email accounts and internet protocol (EP) addresses associated with employees, applications, resources, etc. Data in the repositories frequently overlaps, meaning that some information may be common among more than one repository. In a typical organization, each of the data repositories is independently maintained by the department that owns the repository. For example, the HR department maintains its own employee information, while the IT department maintains its own network information.
Because each of the various remote data repositories is independently maintained by the department that owns the data repository, and there may be data common among them, inconsistencies may arise among the data repositories. For example, the HR department repository may have employee “John Smith,” and may list an email address of “johns@company.com”; the IT department may initially have John Smith's email address as “johns@company.com,” but may change the address to “johns@company.com” when another employee, “John Simpson,” joined the company. Thus, when the IT department changes John Smith's email address in the IT repository, the email address is no longer consistent with John Smith's email address in the HR department repository. For many other reasons, information stored in data repositories may become inconsistent within an organization. Thus, organizations typically attempt to manage their various data repositories so as to keep the information in them consistent, as well as up-to-date, accurate, and readily available.
One technique for managing an organization's data repositories and their associated organizational information involves linking the multiple remote repositories, while allowing each department to independently modify its own repository. A so-called metadirectory system employs such a technique. A metadirectory system is essentially a directory of directories or repositories. In traditional metadirectories, data from each of a number of repositories is received by an associated interface that negotiates between the remote repository and a central repository. The central repository includes data representing a combination of data in all the remote repositories. Each of the interfaces typically executes scripts in response to specified events, such as the hiring/firing of an employee, or the changing of an IP or email address.
Each of the individual remote repositories may employ complex data structures, schemas, and protocols for managing its stored information. The metadirectory system itself therefore may also need to employ a highly complex strategy in order to interact with these separate remote repositories. The complexity of the metadirectory system introduces a number of challenges. Those developing the metadirectory system face a first challenge in designing a metadirectory system that meets the myriad of requirements imposed by the separate data repositories. Developers face a second challenge in subsequently maintaining the metadirectory system so that it continues to meet the changing needs of the business for which it was developed. For instance, changes in the design of a remote repository may require a developer to make corresponding changes in the metadirectory system to ensure that the metadirectory system continues to interact with the remote repository in a desired manner. Alternatively, the business may decide to add a new remote repository or delete a previously used remote repository, which again requires changes to the metadirectory system. As used herein, the task of changing the metadirectory system in any manner is referred to as configuring the metadirectory system.
Configuring the metadirectory system is typically a very burdensome task, as a developer should take great care to ensure that the changes made to one part of the metadirectory system do not adversely affect another part of the metadirectory system. This task is all the more troubling in view of the fact that many businesses regard the integrity of their data repositories as essential to the success of their businesses. Thus, mistakes made in changing the metadirectory system can have the effect of literally crippling the business, resulting in loss of productivity and money. Needless to say, for example, a business will not look too favorably on a developer who introduces errors in a payroll system due to an errant update operation made to the metadirectory system.
In the computer fields, developers commonly test an upgrade on a test (or lab) system prior to implementing the upgrade on the working system used by the business. This working system is commonly called the production system of the business. The test system typically includes the same functionality as the production system, and may have access to all of the repositories used by the business, or some representative sample thereof. In using this approach, the developers aim to detect and remedy any errors in the upgrade prior to it being installed on the production system.
Nevertheless, it is not a simple task to apply this strategy to the configuration of metadirectory systems. This difficulty ensues, in part, from the sheer complexity of the metadirectory system. Even after reaching some assurance that the update is working properly on the test system, a developer may nevertheless introduce errors in duplicating the upgrade in the production system. This is because it is a difficult task to accurately “fit” an upgraded piece of the metadirectory system into its proper “location” in the metadirectory system. The developer must worry about how the upgraded piece impacts and interacts with other pieces that have not been changed, and make appropriate modifications to ensure that the system runs smoothly following an upgrade. Further, there is a possibility that assumptions made in developing a new configuration on the test system do not completely match the conditions present in the production system, potentially resulting in a faulty upgrade. Again, the consequences of a misstep in performing this task can be severe.
Accordingly, there is a need in the art for a reliable and efficient technique for configuring data processing systems, such as metadirectory systems.